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Objective 


Understand  what  technical  debt  is 

Provide  a  different  perspective  on  software  development 
and  architecture  through  managing  technical  debt 
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Support  for  Delivery  Over  Ti 


Projects  should  not  simply  produce  a  product  design; 
they  should  plan  a  desired  state  that  enabies  teams  to  quickiy  deiiver 
reieases  that  stakehoiders  value  (or  in  terms  of  iean  practices,  design  a 
profitabie  operationai  vaiue  stream  for  rapidiy  deiivering  that  product). 

State  of 


F.  Bachnnann,  R.  L.  Nord,  I.  Ozkaya,  “Architectural  Tactics  to  Support  Rapid  and  Agile  Stability.” 
CrossTalk25,  3  (May/June  2012):  20-25. 
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Technical  Debt* 


A  design  or  construction  approach  that's  expedient  in  the 
short  term  but  that  creates  a  technical  context  in  which  the 
same  work  will  cost  more  to  do  later  than  it  would  cost  to  do 
now  (including  increased  cost  over  time)  s.  McConneii 


Some  examples  include: 

•  Continuing  to  build  on  a  foundation  of  poor  quality  legacy  code 

•  Prototype  that  turns  Into  production  code 

•  Increasing  use  of  "bad  patches",  which  increases  number  of  related 
systems  that  must  be  changed  In  parallel 


Term  first  used  by  Cunningham,  W.  1992.  The  WyCash  Portfolio  Management  System.  OOPSLA'92  Experience 
Report,  http://c2.com/doc/oopsla92.html. 
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Technical  Debt  - 

Steve  McConnell 


Typel 

Type  2 

unintentional,  non-strategic; 
poor  design  decisions,  poor 
coding 

intentional  and  strategic:  optimize 
for  the  present,  not  for  the  future. 

2.  A  short-term:  paid  off  quickly 
(refactorings,  etc.) 

2.B  long-term 

Implemented  features  (visible  and  invisible)  =  assets  =  non-debt 

McConnell,  S.  2007.  Technical  Debt.  10x  Software  Development  [cited  2010  June  14]; 
http://blogs.construx.eom/blogs/stevemcc/archive/2007/1 1  /01  /technical-debt-2. aspx. 
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Cost  of  Change  (CoC) 


Technical  Debt  - 

Jim  Highsmith 


Customer 


Years 


Only  on  far  right  of  curve,  all 
choices  are  hard 

If  nothing  is  done,  it  just  gets  worse 

In  applications  with  high  technical 
debt  estimating  is  nearly  impossible 


Highsmith,  J.  2009.  Agile  Project  Management:  Creating  Innovative  Products  ,  Addison-Wesley. 
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Technical  Debt  Analogy 


When  and  how  was  the  debt  signed  under? 
What  is  the  interest  rate? 

What  is  the  payback  strategy? 
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IlliJ 

eiiiB 

S  3 


Taking  on  Debt 

First  more  capabilities 


Then 


underestimated 
re-architecting  costs 


more  infrastructure 


neglected  cost  of 
delay  to  market 


First  more  infrastructure  Then,  more  capabilities 


Brown,  N.,  Nord,  R.,  Ozkaya,  I.  2010.  Enabling  Agility  through  Architecture,  Crosstalk,  Nov/Dec  2010. 
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Understanding  the  interest  rate  - 1 


Standard  iteration  management  in  agile  development 
^  functional,  high-priority  stories  allocated  first. 


Focus  on  Value 


Velocity 


Accumulated  suboptimal 
architecture  and  need  to  wait 


Tracking  and  monitoring  mechanism  is  solely  based  on 
customer  features  delivered. 
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Understanding  the  interest  rate  -  2 


Standard  iteration  management  in  architecture-centric 
development  processes 

^  up-front  requirements  and  design  tasks  allocated  first. 


Focus  on  Cost 


No  explicit  and  early  tracking  and  monitoring  mechanisms  that 
is  development  artifact  specific. 
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Only  Three  Strategies 

Do  nothing,  it  gets  worse 
Replace,  high  cost/risk 

Incremental  refactoring,  commitment  to  invest 
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Tactics  to  consider 


Align  feature  and 
system  decomposition. 


Infrastructure-driven 

approach 

i  Applications  ■  i 
Services  ;J| 


Drivers 

Horizontal  decomposition 
(e.g.,  layers) 


Feature-driven 

approach 


Vertical  decomposition 
(e.g.,  subsystems,  features) 


Hybrid  approach 


I 


UK  Drivers 


Create  an 

architectural  runway. 


Use  matrix  teams 
and  architecture. 


Sprum  of 

Si;mFnE5 
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Why  Should 

Government  Care  About 
Technical  Debt  and 
Software  Architecture? 

Practical  Approaches  from  the  Ground 

Warren  Ellmore  Everw^-CBDI 

NORTH  AMERICA 


Technical  Debt  is  good  (as  long  as  it's  managed) 


•  Technical  Debt  is  essentially  the  result  of  trade-offs  -  deferred  decisions, 
deferred  priorities,  deferred  capabilities,  deferred  skills. 

•  Technical  Debt  arises  when  current  sprint  work  is  unblocked  by  a 
decision  on  what  can  be  implemented  now  and  what  can  be  deferred. 

Example:  You  know  you  need  security  but  decide  to  defer  that  for  a  later  sprint 
so  that  functional  capability  can  continue  to  be  developed/implemented. 

Example:  You  need  to  interface  with  a  legacy  system  but  that  API  isn't  ready  yet 
so  you  decide  to  hack  a  quick  stub  just  for  now. 

Government  Context:  Unfortunately,  Technical  Debt  is  often  misunderstood  by 
business  owners  and  frequently  ignored  in  favor  of  business  functionality. 
Managing  and  resolving  Technical  Debt  is  often  more  difficult  because  of 
contract  terms,  size  and  complexity,  and  a  general  lack  of  skills  and  experience  in 
risk  management  as  it  relates  to  Agile  development. 
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Technical  Debt  can  be  Managed 


•  Requires  more  than  just  logging  a  ''ToDo"  or  adding  to  the 
backlog 

•  All  parties  must  be  involved  and  have  insight  -  PMO  responsibility 

•  Establish  and  refine  an  understanding  of: 

•  Scope  of  impact  and  the  accumulated  risk  curve 

•  "Value'"  and  priority  within  the  release  strategy 

•  Dependencies  of  scheduled  functionality  on  resolution  (partial  or  full) 

•  Ongoing  decisions  can  ease  or  exacerbate  a  particular  debt 

•  Choose  Technologies,  Architectures  and  Frameworks  that  meet 
the  business/mission  requirements  and  minimize  Technical  Debt 
impact 

•  Available  skills,  known  technologies  vs.  new  "shiny  objects" 

•  Leverage  componentization  -  separation  of  concerns,  service 
architecture 

•  Reuse  existing  capability  -  services,  components,  models,  patterns, 

specifications ...  _ 
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Technical  Debt  can  be  addressed 
in  Sprints 


•  Plan  for  periodic  refactoring  sprints 

•  Run  parallel  Architecture/Technical  Capability  sprints 

•  Run  parallel  Integration  sprints  targeting  releases 

•  Start  running  functional/performance  testing  asap  and  scale  with  codebase 


Sprint  0 


5  X  6 
- ^1 


8 


Architecture/Technical 
Capability  sprints 


\  Develop  [l_i  Develop  Develop  Develop  |-l^  Refactor  1'^  it 


Refactor  N 


Integration  sprints 


Framework  |  |  Rules  Eng  |  Auditing]^  Security  ]  Security  ^ 

TTTTU  rW  \ 


Infrastructure 


Ext.  API 


Continuous  Integration/System  Testing 


\  Release 
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Architecture  can  Reduce  the  Accumulation 
and  Impact  of  Technical  Debt 


Aim  for  a  "Fuller-stack"  Service  Architecture 

•  Provides  isolation  reducing  change  impact  scope 

•  Provides  abstraction  for  new/untested  technology 

•  Provides  for  asset/capability  reuse  and  extension 

Leverage  Architectural  Models 

•  Impact  analysis,  traceability,  knowledge 
management 

•  More  easily  identify  separation  points  for  dividing 
the  work  across  multiple 

team  s/co  n  t  ra  cts/ p  ro  vi  d  e  rs 

•  Evolve  to  Model-Driven  Architecture/Development 

•  Business  Process  Orchestration 

•  Code  generation,  injectable  architectural  framework 


Data 

Services 


Channel 

Services 


Business 

Services 


Utility/Proxy 

Services 


External 
Services, 
API's ... 
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Key  Takeaways 


•  Technical  debt  is  unavoidable  and  can  be  good  -  if  managed 

•  Make  architecture  features  and  technical  debt  visible. 

•  Plan  for  its  resolution  -  increase  for  new/unknown 

•  Different  kinds  of  technical  debt  call  for  different  approaches,  e.g. 
new  technology  versus  low  code-quality 

•  Bridge  the  gap  between  the  business  and  technical  sides. 

•  Associate  technical  debt  with  risk. 

•  Reduce  technical  debt  impact  with  architecture  -  sufficient 
upfront,  add  capability  in  parallel  sprints. 

•  Discover  unseen  technical  debt  as  early  as  possible  by 
starting  continuous  integration  and  system  testing  following 
Sprint  1 

•  Integrate  technical  debt  into  planning  and  standard  operating 
procedures  (e.g.,  planning,  reviews,  retrospectives). 
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